Prescriptive analytics based compute sizing correction stack for cloud computing resource scheduling

ABSTRACT

A multi-layer compute sizing correction stack may generate prescriptive compute sizing correction tokens for controlling sizing adjustments for computing resources. The input layer of the compute sizing correction stack may generate cleansed utilization data based on historical utilization data received via network connection. A prescriptive engine layer may generate a compute sizing correction trajectory detailing adjustments to sizing for the computing resources. Based on the compute sizing correction trajectory, the prescriptive engine layer may generate the compute sizing correction tokens that that may be used to control compute sizing adjustments prescriptively.

PRIORITY CLAIM

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 15/922,650, filed Mar. 15, 2018, issuing as U.S.Pat. No. 10,719,344, entitled Prescriptive Analytics Based ComputeSizing Correction Stack for Cloud Computing Resource Scheduling, whichis incorporated by reference in its entirety. U.S. patent applicationSer. No. 15/922,650 claims priority to Indian Patent Application No.201841000310, filed Jan. 3, 2018, entitled Prescriptive Analytics BasedCompute Sizing Correction Stack for Cloud Computing Resource Scheduling,which is incorporated by reference in its entirety.

TECHNICAL FIELD

This disclosure relates to cloud computing resource scheduling via aprescriptive analytics based compute sizing correction stack.

BACKGROUND

Rapid advances in communications and storage technologies, driven byimmense customer demand, have resulted in widespread adoption of cloudsystems for managing large data payloads, distributed computing, andrecord systems. As one example, modern enterprise systems presentlymaintain data records many petabytes in size in the cloud. Improvementsin tools for cloud resource allocation and consumption prediction willfurther enhance the capabilities of cloud computing systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example multiple-layer compute sizing correction stack.

FIG. 2 shows example compute sizing correction stack logic.

FIG. 3 shows an example specific execution environment for the computesizing correction stack of FIG. 1.

FIG. 4 shows an example compute sizing correction control interface.

DETAILED DESCRIPTION

In cloud computing systems, computing resources such as virtualmachines, memory, processor cores, or other computing resources may bescheduled for planned utilization. In some cases, a computing resourcemay itself constitute an over-provisioning or under provisioning. Forexample, a provisioned virtual machine may be utilized sporadically orpartially, such that a virtual machine corresponding to a smallercompute size could fill the demands on the provisioned virtual machine,where size refers to one or more computing capacities of the computingresource. Conversely, a provisioned virtual machine may be usedcontinually or at capacity and may be unable to fulfill computingrequests assigned to it. For example, the virtual machine, in somecases, may reject or be non-responsive to over-capacity requests.Accordingly, an over-sized or under-sized computing resource may lead toperformance degradation or inefficient deployment of hardware resources.

Accordingly, increased compute sizing accuracy provides a technicalsolution to the technical problem of system inefficiency by increasingthe utilization and efficiency of cloud computing resources. The computesizing correction (CSC) stack techniques and architectures describedbelow may be used to prescribe computing resource sizing recommendationsbased on compute utilization sizing criterion. Further, thedetermination of the compute sizing correction may rely on data sourcessuch as, utilization data, expenditure report data for resourcereservation/activation, computing resource consumption metric data,activation request data, functional grouping data, topological orrelationship data, tagging data, or other metadata. Thus, a CSC stackmay provide prescriptive analytical sizing correction taking intoaccount resource utilization patterns, computing resource types,computing resource availability, consumption metric data, workload andtopological data, geographic data, and/or other data. Thus, thedisclosed CSC stack techniques and architectures improve the operationof the underlying hardware by increasing computing efficiency andprovide an improvement over existing solutions.

The CSC stack may analyze historical utilization data, tagging data andconsumption metric data to predict future utilization and produceprescriptive recommendations. Utilization data, may include, forexample, historical data related to usage or activation of cloudcomputing resources, e.g., resource allocation history,activation/reservation/committed-use history data, expenditure reportdata for resource reservation/activation/committed-use, processoractivity, memory usage history, computing cycles, data throughput, orother utilization metrics, seasonal usage cycles e.g., holidayschedules, daily usage cycles, weekly usage cycles, quarterly usagecycles or other data. Tagging data may include computing resourcespecific data. For example, tagging data may include data provided by anoperator, provisioning or configuration management system, or ananalyzed system detailing functional groupings (e.g., project-specificallocations, hardware (including virtualized hardware) marked for aspecific purpose, availability zones, operating systems applications,installed software, or other groupings), quality of servicerequirements, minimum allocations, environmental data, license tags, orother tagging data. Consumption metric data may include computingresource specific cost metrics such as expenditure-per-time orresource-per-time metrics.

FIG. 1 shows an example multiple layer CSC stack 100, which may executeon sizing circuitry making up the hardware underpinning of the CSC stack100. In this example, the CSC stack 100 includes a data staging layer105, an input layer 110, a configuration layer 130, a prescriptiveengine layer 150, a presentation layer 160, and a data export layer 170.The CSC stack 100 may include a multiple-layer computing structure ofhardware and/or software that may provide prescriptive analyticalrecommendations (e.g., static reservation scheduling for virtualmachines or other computing resource activation scheduling) through dataanalysis.

In some implementations, as discussed below, CRSR Engine—a CloudRight-Sizing Recommendation Engine developed by Accenture® Bangalore maybe operated as the CSC stack 100.

A stack may refer to a multi-layered computer architecture that definesthe interaction of software and hardware resources at the multiplelayers. The Open Systems Interconnection (OSI) model is an example of astack-type architecture. The layers of a stack may pass data andhardware resources among themselves to facilitate data processing. Asone example for the CSC stack 100, the data staging layer 105 mayprovide the input layer 110 with storage resources to store ingestedhistorical utilization data within a database. Hence, the data staginglayer 105 may provide a hardware resource, e.g., memory storageresources, to the input layer 110. Accordingly, the multiple-layer stackarchitecture of the CSC stack may improve the functioning of theunderlying hardware.

In the following, reference is made to FIG. 1 and the correspondingexample CSC stack logic (CSCL) 200 in FIG. 2. The logical features ofCSCL 200 may be implemented in various orders and combinations. Forexample, in a first implementation, one or more features may be omittedor reordered with respect to a second implementation. At the input layer110 of the CSC stack 100, the CSCL 200 may obtain historical utilizationdata 112, consumption metric data 114, and tagging data 116 (202) andthen store the obtained data at the data staging layer 105 (204). Insome cases, the historical utilization data 112, consumption metric data114, and tagging data 116 may be received via communication interfaces(e.g., communication interfaces 312, discussed below). The historicalutilization data 112, consumption metric data 114, and tagging data 116may be accessed at least in part, e.g., via the communication interfaces312, from data sources 111, which may include, cloud compute utilizationdatabases, cloud expenditure databases, master virtual machine costdatabases, committed-use history databases, virtual machinefamily/template description data, infrastructure/project tags or otherdata sources. The historical utilization data 112 may be provided bycloud compute utilization databases, cloud expenditure databases,committed-use history databases, or other utilization data sources. Theconsumption metric data 114 may be provided by cloud expendituredatabases, master virtual machine cost databases, virtual machinefamily/template/platform as a service, description data, or otherconsumption metric data sources. The tagging data 116 may be provided byvirtual machine family/template description data, infrastructure/projecttags or other tagging data sources.

After the historical utilization data 112, consumption metric data 114,and tagging data 116 are obtained and stored, the input layer 110 mayaccess the some or all of the stored data (206) using memory resourcespassed from the data staging layer 105 (e.g., memory access resources).The input layer 110 may process the historical utilization data 112 togenerate a cleansed utilization data 122 for the computing resources(207). For example, the input layer may reformat historical utilizationdata obtained from multiple sources into a common format for analysis.The common format may be a selected format to which data in otherformats are translated. In some cases, the cleansed utilization data 122may include a time-correlated history and cycle analysis of pastcomputing resource usage to facilitate determination of likely patternsof future usage, e.g., for individual computing resources, computingresources within a functional group, or other groups of computingresources.

In some cases, the techniques and architectures used in conjunction withan activation timetable stack such as that described in U.S. patentapplication Ser. No. 15/811,339, filed Nov. 13, 2017, entitledPrescriptive Analytics Based Activation Timetable Stack for CloudComputing Resource Scheduling, which is entirely included herein byreference, may be used to perform or assist in generation of thecleansed utilization data 122. Therein, the input layer of theactivation timetable stack may parse historical utilization data,consumption metric data, and tagging data to identify patterns atmultiple timescales. The input layer of the activation timetable stackmay then generate time-correlated consumption data. In an illustrativescenario of how the CSC stack 100 may utilize the activation timetablestack outputs, the parsing of the historical utilization data,consumption metric data, and tagging data, done by the input layer ofthe activation timetable stack may be implemented by the input layer 110of the CSC stack to generate the cleansed utilization data 122 (207).

Additionally or alternatively, to process the stored data 112, 114, 116,the input layer 110 may analyze time components of the stored data 112,114, 116 to determine time related patterns. For example, the inputlayer 110 may identify weekly, monthly, holiday, seasonal, or other timecycles present within the stored data 112, 114, 116. Time-independentdata, such as, non-conditional functional group assignments, may beapplied to all time periods. However, temporal or otherwise dynamicfunctional groupings may be correlated to corresponding timescales.

To generate the cleansed utilization data 122, the input layer 110 maydetermine one or more timescales (e.g., timescales includingtime-invariant contributions) present within the data. For example, theinput layer 110 may apply various frequency analyses to the data todetermine periodic, aperiodic, and/or time-invariant trends.Additionally or alternatively, the input layer 110 may apply rule-basedanalyses such as holiday schedules, operational hours, or annualenterprise cycles that may be expressly defined by rules rather thanthrough inferential analysis.

Once the cleansed utilization data 122 is generated, the input layer 110may store the cleansed utilization data 122, via a database operation atthe data staging layer 105 (208). For example, the cleansed utilizationdata 122 may be stored on storage dedicated to the CSCL 200.Additionally or alternatively, the cleansed utilization data 122 may bestored on a shared database or cloud storage. Accordingly, the datastaging layer 105 may further access network resources (e.g., viacommunication interfaces 312, discussed below) to implement memoryresource provision to the other layers. In an example implementation,the CSCL 200 may be defined within a Revolution-R environment. However,other design platforms may be used.

At the configuration layer 130 of the CSC stack 100, the CSCL 200 maydetermine one or more compute utilization sizing criteria 132 (210). Thecompute utilization sizing criteria 132 may include threshold values,values for extrema (e.g., minimum, maximum), averages, or other criteriafor determining when and how strongly to apply compute sizingcorrection.

The compute utilization sizing criteria 132 may be supplied via operatorinput, e.g., via the CSC control interface 164, as discussed below. Forexample, an operator may select to apply compute sizing correction tocomputing resources with 95^(th) percentile usage below a thresholdvalue (or conversely determine to not compute sizing correctioncomputing resources with 95^(th) percentile usage above a minimumthreshold value).

Once, the CSCL 200 determines the compute utilization sizing criteria132, the CSCL 200 may store the compute utilization sizing criteria 132via operation at the data staging layer 105 (212).

The prescriptive engine layer 150 may access the cleansed utilizationdata 122 and/or the compute utilization sizing criteria 132 using amemory resource provided by the data staging layer 105 (214). Forexample, the data staging layer 105 may provide a memory read resource(such as a SQL database read resource) to the prescriptive engine layer150 to allow access to the cleansed utilization data 122.

Using the cleansed utilization data 122 and/or the compute utilizationsizing criteria 132, the CSCL 200, at the prescriptive engine layer 150,may determine to apply compute sizing correction to one or morecomputing resources (216). The determination may include predictingfuture utilization based on the time patterns extracted in the cleansedutilization data 122 generated at the input layer (or received, e.g.,from an activation timetable stack, at the input layer).

In an illustrative example, the prescriptive engine layer 150 mayimplement the example routine in Table 1 to determine a CSC trajectoryfor a computing resource.

TABLE 1 Example Routine for Determination of CSC Trajectory DescriptionExample Right-Size* = = If α(t) <= π OR [(α(t) > π) & (P95(t) < μ)Routine α(t): Max utilization value for a time period “t”. π: Maxutilization threshold value (example compute utilization criterion).P95(t): 95^(th) percentile utilization value for the time period “t”. μ:P95 threshold utilization value (example compute utilization criterion).

In some implementations, the CSCL 200 may further determine a CSCtrajectory 152 for a computing resource (218). A CSC trajectory 152 mayinclude a target, or other estimated sizing, for a computing resource.The CSC trajectory 152 may further detail one or more CSC cycleadjustments 154 that may indicate intermediate compute sizing correctionsteps to progress towards the target sizing. The compute sizingcorrection steps in some cases may correspond to an allowed adjustmentwithin a cycle (e.g., billing period, interval, or other time period).Detailing an allowed adjustment may prevent the CSCL 200 from adjustinga computing resource at a rate that may produce unexpected results. Forexample, a CSC stack may constrain sizing adjustments to one sizingincrement per cycle. However, other adjustment constraints may be used.

In some implementations, CSCL 200 may apply a binary compute sizingcorrection determination. For example, the CSCL 200 may determine whichcomputing resources will have compute sizing correction applied. Then,the CSCL 200 may prescribe a unitary sizing adjustment (eitherincrementing the sizing or decrementing the sizing) to each of thedetermined computing resources. In such a binary compute sizingcorrection determination, the CSC trajectory corresponds to the unitaryincrement/decrement and the CSC cycle adjustment 154 also corresponds tothe unitary increment/decrement.

In some implementations, to determine the target sizing, the CSCL 200may determine the sizing for the computing resource that would cause itto meet the compute utilization sizing criteria 132 based on thecleansed utilization data available for the computing resource.

In some cases, the CSCL 200 may further account for static reservationin compute sizing correction determinations. For example, the CSCL 200may avoid applying sizing corrections to statically reserved computingresources (or computing resources for which static reservation isprescribed or planned). Accordingly, the CSCL 200 may increase sizingcorrections (or the magnitude of such corrections). e.g., relative toinitial sizing adjustment determinations, on dynamically reservedcomputing resources to avoid applying compute sizing correction tostatically reserved computing resources. Accordingly, the CSCL 200 mayreduce or eliminate a determined sizing reduction for a staticallyreserved computing resource or increase a sizing reduction for adynamically reserved computing resource when other computing resourcesin the same functional group are statically reserved. Accordingly, theCSCL 200 may shift computing load to statically reserved computingresources from dynamically reserved computing resources.

In some implementations, the CSCL 200 may identify statically anddynamically reserved computing resources by accessing a reservationmatrix, such as that generated by a committed compute reservation stacksuch as that described in Indian Patent Application No. 201741044406,filed Dec. 11, 2017, entitled Prescriptive Analytics Based CommittedCompute Reservation Stack for Cloud Computing Resource Scheduling, whichis incorporated by reference in its entirety. The reservation matrix maydetail a distribution of statically and dynamically computing resources.In some implementations, the CSCL 200 may exhaust sizing adjustments fordynamically provisioned computing resources before applying sizingadjustment to statically reserved resources. In some implementations,the CSCL 200 may engage in an iterative sizing determination scheme witha committed compute reservation stack. The committed compute reservationstack may designate an initial distribution of static and dynamiccomputing resources. Then, the CSCL 200 may make sizing adjustments. Thecommitted compute reservation stack may again adjust the distributionand the CSCL 200 may make further sizing adjustments. The iterativeadjustment process may continue eventually reaching a steady statedistribution and sizing determination.

In some implementations, CSCL 200, at the prescriptive engine layer 150,may alter the CSC trajectories 152 and/or CSC cycle adjustments 154based on learned preferences from operator command feedback history. Forexample, the prescriptive engine layer 150 may account for consumptionsavings patterns within operator comments. For example, some operatorsmay aggressively pursue sizing reductions. Accordingly, the CSCL 200 maypreemptively increase prescribed sizing reductions and/or preemptivelydecrease prescribed sizing increases. Conversely, an operator maydemonstrate a reluctant to pursue sizing reductions and the prescriptiveengine layer may adjust its prescriptions in the opposite direction. Insome cases, operators may demonstrate functional group specificpreferences. For example, operators may resist sizing adjustments tospecific functional groups, while freely accepting prescriptions forsizing in other functional groups. Accordingly, the prescriptive enginelayer 150 may apply machine learning to identify such patterns withinoperator commands and preemptively adjust the prescriptions produced tomore closely match operator preferences.

In some implementations, CSC trajectories and/or CSC cycle adjustments154 may involve sizing adjustments that port computing resources acrossservices, vendors, hardware platforms, or other characteristics. TheCSCL 200 may apply rules to ensure the preservation of selectedcharacteristics, e.g., operating system, region, security, networkingthroughput, or other characteristics, of the computing resources acrosssuch transactions. For example, when porting across vendors to implementa sizing adjustment, the CSCL 200 may ensure that the operating systemused by the replacement computing resource is the same as that beforethe transition. The CSCL 200 may also disallow certain transitions. Forexample, some implementations may disallow sizing transitions involvingvendor changes.

Referring again to FIGS. 1 and 2, the CSCL 200 may store the CSCtrajectories 152 for the computing resources, via interaction with thedata staging layer (220).

The presentation layer 160 may then access the CSC trajectories for thecomputing resources (222). The presentation layer 160 may merge the CSCtrajectories and CSC cycle adjustments with consumption metric data togenerate consumption saving data corresponding to the CSC trajectoriesand CSC cycle adjustments. The presentation layer 160 may sort thecomputing resources according to consumption savings, functional groups,sizing adjustment magnitude, or other variables. The presentation layer160 may generate the CSC control interface 164 and populate theCSC-window presentation 166 with the CSC trajectories and CSC cycleadjustments and accompanying data and options (224).

The CSC control interface may receive operator commands, e.g., acceptingand/or rejecting prescribed sizing adjustments (226). The CSCL 200 mayincorporate the operator commands, and, at the prescriptive engine layer150, generate a CSC token 156 (228). The CSC token 156 may includecommands, scripts, or other code to cause host interfaces forcontrolling the respective computing resources to implement the sizingadjustments. For example, services such as Amazon® Web Services (AWS),Google® Compute Engine, Microsoft® Azure, or other cloud computingservices, may maintain host interfaces (e.g., web interfaces,application programming interfaces, or other interfaces) by whichclients may define operation of the computing resources. The CSCL 200may also use a scheduling proxy system that uses the CSC trajectorydata, CSC cycle adjustment data, and operator command data to maintainschedules, calling the service provider's application programminginterfaces, e.g., by sending a CSC token, for each sizing adjustmentcontrol action defined by the schedules. The CSCL 200 may use thecommunication interfaces 312 to send the CSC tokens to the hostinterfaces (230).

In an illustrative example scenario, the CSCL 200 may implement theexample routine in Table 2 to generate a CSC token starting from datareceived at the input layer 110.

TABLE 2 Example Routine for Determination of CSC Token Description Ex-Input: Utilization database (Db), Billing Db, Cost Db, Committed ampleCompute (CC) Purchase Db Rou- Output: Sizing Adjustment tine Step1: Loadthe input files Step2: Cleanse the data  Step2a: Select the requiredvariables for analysis  Step2b: Rename the variables  Step2c: Format thevariables (date, numeric and string) Step3: Selecting the maximumutilization  Step3a: for each resource id (1, n) sort utilization valueby date and value  Step3b: for each resource id (1, n) select maximumvalue for each hour Step4: Filtering billing data for EC2 instances Step4a: Select for “Box-Usage” under “Usage Type” Step5: MergeUtilization, Billing, Cost Files and CC purchase history  Step5a: MergeUtilization and Billing files by resource id  Step5b: Merge the outputof Step5a with the Cost file (to extract the information of down-sizedrecommendation VM cost)  Step5c: Merge CC purchase history to extractthe number of CC coupons per VM type Step6: Calculating the 95^(th)percentile utilization value  Step6a: Calculate the 95^(th) percentilevalue for each resource id (1, n) Step7: Recommendation Flag generation Step7a: Right-Size = = If α(t) <= π OR [(α(t) > π) & (P95(t) < μ)where,  α(t) = maximum utilization value for the given time-period “t” π = maximum utilization threshold value  P95(t) = 95^(th) percentileutilization value for the given time- period “t”  μ = P95 thresholdutilization value Step8: Calculate the “potential savings” (if theRight-Size (RS) recommendations are accepted)  Step8a: Potential Savings= On Demand Cost − Down-size machine Cost Step9: Remove the duplicaterecords and generate the recommendations for each resource id Step10: RSCC computation  Step10a: Sort the resource id's by VM type, RSrecommendation  ≠ Right-size and potential savings by ascending order Step10b: Exhaust the existing Reserved instances in the order as above Step10c: Remaining RS recommendations represent the RS potentialsavings Step11: Binning the resource id's based on “potential savings” Step 11a: Bin = ‘High’ if savings <= 65%, ‘Medium’ if 65% <=  savings<= 85%, ‘Low’ if 85% <= savings Step12: Generate the final output

In some cases, the CSCL 200 may initiate deployment via the data exportlayer 170. The data export layer 170 may format the reservation matrixin one or more formats for transfer. For example the data export layer170 may support format translation to java script object notation(JSON), eXtensible markup language (XML), comma separated value (CSV),Tableau Workbook (TBWX), hyper-text markup language (HTML) or otherformats. The data export layer 170 may also support transfer of thereservation matrix in one or more states, such as flat file transfers,streaming transfers, web service access, internet protocol transfers, orother transfers.

Additionally or alternatively, the CSCL 200 may initiate deployment viathe prescriptive engine layer 150 through direct transfer, directnetwork access, or other non-export transfer.

FIG. 3 shows an example specific execution environment 300 for the CSCstack 100 described above. The execution environment 300 may includesizing circuitry 314 to support execution of the multiple layers of CSCstack 100 described above. The system logic may include processors 316,memory 320, and/or other circuitry.

The memory 320 may include analytic model parameters 352, machinelearning heuristics 354, and operational rules 356. The memory 320 mayfurther include applications and structures 366, for example, codedobjects, machine instructions, templates, or other structures to supportcleansed utilization data generation or other tasks described above. Theapplications and structures may implement the CSCL 200.

The execution environment 300 may also include communication interfaces312, which may support wireless, e.g. Bluetooth, Wi-Fi, WLAN, cellular(4G, LTE/A), and/or wired, Ethernet, Gigabit Ethernet, opticalnetworking protocols. The communication interfaces 312 may also includeserial interfaces, such as universal serial bus (USB), serial ATA, IEEE1394, lighting port, I²C, slimBus, or other serial interfaces. Thecommunication interfaces 312 may be used to support and/or implementremote operation of the CSC control interface 164. The executionenvironment 300 may include power functions 334 and various inputinterfaces 328. The execution environment may also include a userinterface 318 that may include human-to-machine interface devices and/orgraphical user interfaces (GUI). The user interface 318 may be used tosupport and/or implement local operation of the CSC control interface164. In various implementations, the sizing circuitry 314 may bedistributed over one or more physical servers, be implemented as one ormore virtual machines, be implemented in container environments such asCloud Foundry or Docker, and/or be implemented in Serverless (functionsas-a-Service) environments.

In some cases, the execution environment 300 may be a specially-definedcomputational system deployed in a cloud platform. In some cases, theparameters defining the execution environment may be specified in amanifest for cloud deployment. The manifest may be used by an operatorto requisition cloud based hardware resources, and then deploy thesoftware components, for example, the CSC stack 100, of the executionenvironment onto the hardware resources. In some cases, a manifest maybe stored as a preference file such as a YAML (yet another mark-uplanguage), JSON, or other preference file type.

Referring now to FIG. 4, an example CSC control interface 164 is shown.The CSC control interface 164 includes an example CSC-windowpresentation 166 as discussed above. The CSC-window presentation 166 mayinclude multiple selectable options 412, 414, 416, 418, 420, 422 anddata regarding the CSC trajectories and CSC cycle adjustments before andafter alteration to accommodate the learned preferences of the operator.In this example scenario, the selectable options may include aprescribed-accept option 412 to implement some or all of the prescribedsizing adjustments as a group without alteration based on learnedpreferences, a complete-accept option 414 to implement the sizingadjustments with alterations based on learned preferences, options 416,418, 420 to implement augments to selected subsets of the computingresources, option 422 to adjust preferences (e.g., thresholds, extrema,or other compute utilization sizing criteria) and re-run the routine atthe prescriptive engine layer 150, or other selectable options tocontrol the eventual CSC token output.

Additionally or alternatively, the CSC-window presentation 166 mayinclude selection and filter tools 432, 434 to support granularmanipulation of the sizing adjustments, e.g., by computing resource, byfunctional group, resource region, operating system, or other granularmanipulation. The CSC-window presentation 166 may also include exporttools 436 for management of data export layer 170 operations.

In some implementations, the CSC-window presentation 166 may include afunctional group detail panel 440 for management of group-levelselectable options such as group level approvals of static reservations.Additionally or alternatively, the functional group detail panel 440 maydisplay group-level information regarding static reservations.Functional group detail panel 440 may also provide an option to rollback previously approved static reservations.

In the example, shown in FIG. 4, the options 416, 418, 420 allow formanipulation of selected subsets of the computing resources. Forexample, as shown the example routine in table two, the sizingadjustments may be “binned” into consumption savings classes. Forexample, “high”, “medium”, and “low” consumption savings bins may allowthe operator to select specific groups of sizing adjustments. Theoptions 416, 418, 420 show the respective portions of the totalconsumption savings that may be achieved by adjusting each specificsubset of the computing resources. In the example, the first subsetoption 416 provides the greatest marginal consumption savings, while theoptions 418, 420 provide successively smaller marginal consumptionsavings.

The methods, devices, processing, circuitry, and logic described abovemay be implemented in many different ways and in many differentcombinations of hardware and software. For example, all or parts of theimplementations may be circuitry that includes an instruction processor,such as a Central Processing Unit (CPU), microcontroller, or amicroprocessor; or as an Application Specific Integrated Circuit (ASIC),Programmable Logic Device (PLD), or Field Programmable Gate Array(FPGA); or as circuitry that includes discrete logic or other circuitcomponents, including analog circuit components, digital circuitcomponents or both; or any combination thereof. The circuitry mayinclude discrete interconnected hardware components or may be combinedon a single integrated circuit die, distributed among multipleintegrated circuit dies, or implemented in a Multiple Chip Module (MCM)of multiple integrated circuit dies in a common package, as examples.

Accordingly, the circuitry may store or access instructions forexecution, or may implement its functionality in hardware alone. Theinstructions may be stored in a tangible storage medium that is otherthan a transitory signal, such as a flash memory, a Random Access Memory(RAM), a Read Only Memory (ROM), an Erasable Programmable Read OnlyMemory (EPROM); or on a magnetic or optical disc, such as a Compact DiscRead Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic oroptical disk; or in or on another machine-readable medium. A product,such as a computer program product, may include a storage medium andinstructions stored in or on the medium, and the instructions whenexecuted by the circuitry in a device may cause the device to implementany of the processing described above or illustrated in the drawings.

The implementations may be distributed. For instance, the circuitry mayinclude multiple distinct system components, such as multiple processorsand memories, and may span multiple distributed processing systems.Parameters, databases, and other data structures may be separatelystored and managed, may be incorporated into a single memory ordatabase, may be logically and physically organized in many differentways, and may be implemented in many different ways. Exampleimplementations include linked lists, program variables, hash tables,arrays, records (e.g., database records), objects, and implicit storagemechanisms. Instructions may form parts (e.g., subroutines or other codesections) of a single program, may form multiple separate programs, maybe distributed across multiple memories and processors, and may beimplemented in many different ways. Example implementations includestand-alone programs, and as part of a library, such as a shared librarylike a Dynamic Link Library (DLL). The library, for example, may containshared data and one or more shared programs that include instructionsthat perform any of the processing described above or illustrated in thedrawings, when executed by the circuitry.

Various implementations may use the techniques and architecturesdescribed above.

A1 In an example, a system includes: network interface circuitryconfigured to: receive historical utilization data for a selectedvirtual machine; receive consumption metric data for the selectedvirtual machine; send a compute sizing correction (CSC) token to a hostinterface configured to control requisition for at least the selectedvirtual machine; sizing circuitry in data communication with the networkinterface circuitry, the sizing circuitry configured to execute a CSCstack, the CSC stack including: a data staging layer; an input layer; aconfiguration layer; and a prescriptive engine layer; the CSC stackexecutable to: obtain, via the input layer, the historical utilizationdata, and the consumption metric data; process, at the input layer, thehistorical utilization data to generate cleansed utilization data;store, at the data staging layer, the cleansed utilization data, and theconsumption metric data; determine, at the configuration layer, acompute utilization sizing criterion; store, at the data staging layer,the a compute utilization sizing criterion; access, at the prescriptiveengine layer, the cleansed utilization data and the compute utilizationsizing criterion via a memory resource provided by the data staginglayer; based on the cleansed utilization data and the computeutilization sizing criterion, determine, at the prescriptive enginelayer, a CSC trajectory for the selected virtual machine; based on theCSC trajectory, determine a CSC cycle adjustment for the selectedvirtual machine; based on the CSC cycle adjustment, generate the CSCtoken.

A2 The system of example A1, where the CSC stack further includes apresentation layer configured to generate CSC-window presentation withina CSC control interface.

A3 The system of example A1 or A2, where the CSC stack is configured tofurther determine the CSC token based on a feedback history generatedusing previous command inputs from a CSC control interface generated ata presentation layer of the CSC stack.

A4 The system of any of claims A1-A4, where the CSC-window presentationincludes a selectable option to implement the CSC cycle adjustment, theCSC trajectory, or both.

A5 The system of any of examples A2-A4, where the CSC cycle adjustmentis grouped within the CSC-window presentation with other CSC cycleadjustments corresponding to consumption savings within a pre-definedrange.

A6 The system of any of examples A2-A5, where the CSC-windowpresentation includes a summary table detailing CSC cycle adjustmentsfor multiple virtual machines.

A7 The system of any of examples A2-A6, where the CSC-windowpresentation includes an option to reject one or more CSC cycleadjustments.

A8 The system of any of examples A1-A7, where the CSC stack isconfigured to receive, at the input layer, the historical utilizationdata from an activation timetable stack.

A9 The system of any of examples A1-A8, where the CSC stack isconfigured to receive, at the input layer, a reservation matrixdetailing a static reservation for specific virtual machine.

A10 The system of example A9, where the CSC stack is further configuredto: decrease a reduction in sizing for the selected virtual machine whenthe selected and specific virtual machines include the same virtualmachine; and increase a reduction in sizing when the selected virtualmachine is different from the specific virtual machine but in a samefunctional grouping as the specific virtual machine.

A11 The system of example A10, where the CSC stack is further configuredto decrease a reduction in sizing for the selected virtual machine byrejecting the CSC trajectory for the selected virtual machine.

A12 The system of any of examples A1-A11, where the CSC token isconfigured to alter a compute capability for the selected virtualmachine while preserving a selected operating system, region, networkingthroughput, or any combination thereof for the selected virtual machine.

A13 The system of any of examples A1-A12, where the CSC token, when sentto the host interface, causes the host interface to implement the CSCcycle adjustment.

B1 In an example, a method includes: at network interface circuitry:receiving historical utilization data for a selected virtual machine;and receiving consumption metric data for the selected virtual machine;at sizing circuitry in data communication with the network interfacecircuitry, the sizing executing a compute sizing correction (CSC) stack:obtaining, via an input layer of the CSC stack, the historicalutilization data, and the consumption metric data; processing, at theinput layer, the historical utilization data to generate cleansedutilization data; storing, at a data staging layer of the CSC stack, thecleansed utilization data, and the consumption metric data; determining,at a configuration layer of the CSC stack, a compute utilization sizingcriterion; and storing, at the data staging layer, the a computeutilization sizing criterion; at a prescriptive engine layer of the CSCstack: accessing the cleansed utilization data and the computeutilization sizing criterion via a memory resource provided by the datastaging layer; based on the cleansed utilization data and the computeutilization sizing criterion, determining, at the prescriptive enginelayer, a CSC trajectory for the selected virtual machine; based on tothe CSC trajectory, determining a CSC cycle adjustment for the selectedvirtual machine; and based on the CSC cycle adjustment, generating a CSCtoken; and sending, via network interface circuitry, the CSC token to ahost interface configured to control requisition for at least theselected virtual machine.

B2 The method of example B1, further including generating, at apresentation layer of the CSC stack, a CSC-window presentation within aCSC control interface.

B3 The method of example B2, where determining the CSC token is furtherbased on a feedback history generated using previous command inputs fromthe CSC control interface.

B4 The method of example B2 or B3, where the CSC-window presentationincludes a selectable option to implement the CSC cycle adjustment, theCSC trajectory, or both.

B5 The method of any of examples B1-B4, where the CSC token causes thehost interface to implement the CSC cycle adjustment.

C1 In an example, a product includes: machine-readable media other thana transitory signal; and instructions stored on the machine-readablemedia, the instructions configured to, when executed, cause a machineto: at network interface circuitry: receive historical utilization datafor a selected virtual machine; and receive consumption metric data forthe selected virtual machine; at sizing circuitry in data communicationwith the network interface circuitry, the sizing executing a computesizing correction (CSC) stack: obtain, via an input layer of the CSCstack, the historical utilization data, and the consumption metric data;process, at the input layer, the historical utilization data to generatecleansed utilization data; store, at a data staging layer of the CSCstack, the cleansed utilization data, and the consumption metric data;determine, at a configuration layer of the CSC stack, a computeutilization sizing criterion; and store, at the data staging layer, thea compute utilization sizing criterion; at a prescriptive engine layerof the CSC stack: access the cleansed utilization data and the computeutilization sizing criterion via a memory resource provided by the datastaging layer; based on the cleansed utilization data and the computeutilization sizing criterion, determine, at the prescriptive enginelayer, a CSC trajectory for the selected virtual machine; based on tothe CSC trajectory, determine a CSC cycle adjustment for the selectedvirtual machine; and based on the CSC cycle adjustment, generate a CSCtoken; and send, via network interface circuitry, the CSC token to ahost interface configured to control requisition for at least theselected virtual machine to cause the host interface to implement theCSC cycle adjustment.

C2 The product of example C1, where the instructions are furtherconfigured to cause the machine to receive, at the input layer, areservation matrix detailing a static reservation for specific virtualmachine.

C3 The product of example C2, where the instructions are furtherconfigured to cause the machine to: decrease a reduction in sizing forthe selected virtual machine when the selected and specific virtualmachines include the same virtual machine; and increase a reduction insizing when the selected virtual machine is different from the specificvirtual machine but in a same functional grouping as the specificvirtual machine.

C4 The product of example C3, selected virtual machine by rejecting theCSC trajectory for the selected virtual machine.

D1 A method implemented by operation of a system of any of examplesA1-A13.

E1 A product comprising instructions stored on a machine readablemedium, the instructions configured to cause a machine to implement themethod of example D1.

Various implementations have been specifically described. However, manyother implementations are also possible.

What is claimed is:
 1. A system including: network interface circuitryconfigured to: receive historical utilization data for a selectedvirtual machine; receive consumption metric data for the selectedvirtual machine; send a compute sizing correction (CSC) token to a hostinterface, the host interface configured to control requisition for atleast the selected virtual machine; sizing circuitry in datacommunication with the network interface circuitry, the sizing circuitryconfigured to execute a CSC stack, the CSC stack including: a datastaging layer; an input layer; a configuration layer; and a prescriptiveengine layer; the CSC stack executable to: obtain, via the input layer,the historical utilization data, and the consumption metric data;process, at the input layer, the historical utilization data to generatecleansed utilization data; store, at the data staging layer, thecleansed utilization data, and the consumption metric data; determine,at the configuration layer, a compute utilization sizing criterion;store, at the data staging layer, the compute utilization sizingcriterion; access, at the prescriptive engine layer, the cleansedutilization data and the compute utilization sizing criterion via amemory resource provided by the data staging layer; based on thecleansed utilization data and the compute utilization sizing criterion,determine, at the prescriptive engine layer, a CSC trajectory for theselected virtual machine; based on the CSC trajectory, determine a CSCcycle adjustment for the selected virtual machine; and based on the CSCcycle adjustment, generate the CSC token.